iT邦幫忙

2021 iThome 鐵人賽

DAY 29
0

分散式資料庫理論上會把業務的loading平均分佈到各個node上。但是仍有可能因為業務邏輯或者資料庫本身的機制導致失衡,熱點便是這些情況下的產物。loading只落在其中一個node上,導致整個cluster的效能低落。

TiDB的熱點是怎麼產生的,與資料分配的Key ID有關。TiDB對每一張表、索引、每一行資料都會分配一個ID。
TiKV保存資料的方式是把一連串連續的Key保存在一個Region裡,當達到特定大小的時候,會分裂成兩個Region。
當我們寫入的資料是依序的,如前面提到的Auto_increment,此時Region雖然會因為資料持續寫入達到設定的大小而分裂出新的Region,但是實際上還是針對一個Region做寫入。遇到高併發的寫入時便對寫入產生了熱點。

我們可以從grafana的監控上查看目前是否存在讀/寫的熱點。
https://ithelp.ithome.com.tw/upload/images/20210927/20113220cTX1ic65MX.png
也可以下語法查看

select * from information_schema.TIDB_HOT_REGIONS where type = 'read'
select * from information_schema.TIDB_HOT_REGIONS where type = 'write'

讀取的熱點通常發生在表的本身資料不多,所以region也少。TiKV提供了Load Base Split的方式,依據這兩個參數split.qps-threshold與split.byte-threshold,每十秒QPS與流量的統計值來協助判斷是否要拆分新的Region。qas預設是3000,流量則是30MB/s。

寫入熱點的解決分式,則可以透過SHARD_ROW_ID_BITS把ROWID寫入不同的Region,但是在使用上只限於使用NONCLUSTERED Primary Key的表。除此之外也可以用AUTO_RANDOM替換AUTO Increment。


上一篇
D28 - 壓測
下一篇
D30 - Keep Going
系列文
TiDB學習筆記30
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言